跳到主要内容

创建浏览器小游戏

让 Codex 规划规则、实现浏览器游戏、调试交互，并在浏览器中测试主要流程。

场景定位​

这个案例属于“产品、设计与前端原型”。它适合把一个经常需要人工整理、判断或验证的流程交给 Codex 做第一轮处理，然后由你审阅关键结果。

项目内容
适合任务让 Codex 规划规则、实现浏览器游戏、调试交互，并在浏览器中测试主要流程。
常用能力游戏原型、Canvas、浏览器测试
产出形态清单、草稿、补丁、报告、截图、表格或可运行原型，取决于具体任务

适合谁​

  • 想做教学或营销小游戏
  • 需要快速验证玩法
  • 希望 Codex 自测交互

Codex 可以帮你做什么​

  • 拆解游戏目标和规则
  • 实现状态、计分和失败条件
  • 添加重开、暂停或关卡逻辑
  • 在浏览器中测试操作流程

推荐工作流​

  1. 先写清游戏规则和胜负条件
  2. 说明输入方式和目标设备
  3. 优先使用成熟库处理复杂物理或规则
  4. 让 Codex 自测一局
  5. 检查性能和移动端操作

示例提示词​

请做一个浏览器小游戏：玩家在 60 秒内拖拽元素完成排序。先写游戏规则和状态机，再实现页面、计分、失败条件和重开按钮，最后用浏览器测试核心流程。

案例重点展开​

  • 先让 Codex 写 PLAN.md，明确玩法、状态、资源、输入和验收方式。
  • 用 AGENTS.md 固化技术栈、测试方式和游戏开发注意事项。
  • 需要视觉资产时，可以让 Codex 使用 ImageGen 生成。
  • 使用 Playwright 在真实浏览器里测试游戏开始、失败、重开和计分。
  • 让 Codex 持续迭代时，要检查实际可玩性而不只是日志。

完整用法拆解​

1. 先把任务范围说清楚​

这个案例的重点不是让 Codex 猜你的真实需求，而是把“让 Codex 规划规则、实现浏览器游戏、调试交互，并在浏览器中测试主要流程。”拆成一组可以检查的步骤。开始时先说明输入来源、时间范围、目标对象和最终产物。如果任务涉及多个工具，也要告诉 Codex 哪些工具可以读、哪些动作只能准备草稿。

可以把范围写成三句话：我要处理什么资料、希望得到什么结果、哪些事情不能自动执行。对于“产品、设计与前端原型”这类任务，范围越清楚，Codex 越容易把注意力放在真正有价值的判断上。

2. 让 Codex 先输出中间结果​

不要一上来要求最终答案。更稳妥的方式是先让 Codex 完成“拆解游戏目标和规则”，再让它解释判断依据。这样你可以在中间阶段纠偏，避免它把不重要的信息写进最终产物。

如果任务比较长，可以要求 Codex 先给你一个小型样例，例如前 5 条记录、前 3 个页面、一个模块或一封邮件。样例通过后，再扩大到完整范围。

3. 把工具和证据写进交付物​

这个场景常用能力包括：游戏原型、Canvas、浏览器测试。让 Codex 使用这些能力时，最好要求它把依据也写出来：读了哪些文件、参考了哪些消息、运行了哪些命令、看到哪些截图或日志。

证据不是为了增加篇幅，而是为了让你能判断结果是否可靠。特别是 想做教学或营销小游戏，更应该看到来源、假设和未确认问题。

4. 逐轮校准，而不是一次到位​

第一次结果通常是校准样本。你可以告诉 Codex 哪些判断正确、哪些内容太泛、哪些边界必须更严格。经过几轮之后，再考虑把流程保存为技能、自动化或长期 goal。

一个可用的校准顺序是：先写清游戏规则和胜负条件；说明输入方式和目标设备；最后 检查性能和移动端操作。这样既能提高产出质量，也能减少误操作。

更多提示词案例​

入门版​

请做一个浏览器小游戏：玩家在 60 秒内拖拽元素完成排序。先写游戏规则和状态机，再实现页面、计分、失败条件和重开按钮，最后用浏览器测试核心流程。

请先只处理一个小范围样例，并说明你的判断依据、输出结构和需要我确认的问题。

进阶版​

请把“创建浏览器小游戏”作为一个完整工作流来执行。
目标：让 Codex 规划规则、实现浏览器游戏、调试交互，并在浏览器中测试主要流程。
可用能力：游戏原型、Canvas、浏览器测试
请按以下步骤进行：
1. 先确认输入来源和任务范围。
2. 输出执行计划和风险边界。
3. 生成第一版结果。
4. 标注每个关键结论的依据。
5. 列出需要我确认的问题。
不要执行发送、删除、付款、发布、承诺等不可逆动作。

复盘版​

请复盘刚才这次“创建浏览器小游戏”任务。
请输出：
1. 哪些输入最有用；
2. 哪些判断仍然不确定；
3. 哪些步骤可以下次自动化；
4. 哪些动作必须继续人工确认；
5. 下一次我应该怎样给你更好的上下文。

自动化前校准版​

我想把这个流程以后重复使用，但现在先不要自动化。
请根据本次任务整理一个可复用流程：触发条件、输入来源、处理步骤、输出格式、验证方式、停止条件和人工确认点。
尤其注意：复杂游戏不要手写底层引擎。

交付物检查清单​

完成这类任务后，建议检查以下内容：

  • 是否清楚说明了输入来源、处理范围和时间范围。
  • 是否把“拆解游戏目标和规则”和“实现状态、计分和失败条件”的依据写出来。
  • 是否列出了不确定信息、缺失材料和需要你确认的问题。
  • 是否避免了越权动作，尤其是发送、删除、付款、发布、承诺和修改生产数据。
  • 是否留下了下一步可以继续执行的清单、文件、补丁、报告或验证结果。

使用边界​

  • 复杂游戏不要手写底层引擎
  • 游戏体验必须实际玩一遍
  • 移动端触控和桌面鼠标要分开检查